spec: hide Warp icon from the Dock when using Hotkey window by oz-for-oss[bot] · Pull Request #9349 · warpdotdev/warp

oz-for-oss · 2026-04-29T00:41:32Z

Summary

Adds a product spec for a macOS-only opt-in setting to hide Warp from the Dock while using the dedicated Hotkey window.
Adds a tech spec grounded in the current global hotkey, Quake Mode, settings UI, and macOS platform code paths.
Captures recovery safeguards, including restoring the Dock icon when the user leaves dedicated Hotkey window mode or removes the configured hotkey.

Related issue: #1154

Validation

Ran git diff --check.

Conversation: https://app.warp.dev/conversation/7fcceaef-5e61-49c5-947c-c712b879a392
Run: https://oz.warp.dev/runs/019dd6a8-6e80-78e2-bb23-8662b8fdc98f
This PR was generated with Oz.

Co-Authored-By: Zach Lloyd <zachlloyd@users.noreply.github.com>

oz-for-oss · 2026-04-29T00:42:35Z

@oz-for-oss[bot]

I'm starting a first review of this spec-only pull request.

You can follow along in the session on Warp.

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

I completed the review and posted feedback on this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR adds product and technical specs for a macOS-only, opt-in setting that hides Warp from the Dock while the dedicated Hotkey window workflow is active. The specs define default behavior, recovery safeguards, platform API work, settings/UI integration, telemetry constraints, and validation coverage.

Concerns

No blocking concerns found. The open UX choices are explicitly bounded, and the technical spec provides feasible implementation paths consistent with the referenced settings, hotkey, and macOS platform layers.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss

Overview

This PR adds product and technical specs for a macOS-only opt-in setting that hides Warp from the Dock when the dedicated Hotkey window workflow is enabled.

Concerns

The recovery safeguard is based on a configured keybinding, but the current global shortcut registration path can fail without surfacing success to the proposed effective-state logic; the spec should require a successful registration or a visible-Dock fallback.
The product spec still leaves persistence/sync scope as an open question even though the behavior and tech spec assume storage with existing dedicated Hotkey window settings.

Verdict

Found: 0 critical, 2 important, 0 suggestions

Request changes

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

oz-for-oss · 2026-04-29T00:45:40Z

+7. Warp disappears from the Dock but remains running and responding to the registered global hotkey.
+8. If the user disables the setting, clears the keybinding, or changes global hotkey mode, the same effective-state code restores regular activation policy and the Dock icon returns.
+## Risks and mitigations
+1. Risk: Users can lose their obvious app entry point if the Dock icon is hidden without a working hotkey. Mitigation: effective Dock hiding requires a configured dedicated Hotkey window keybinding and restores the Dock icon when the keybinding is removed.


⚠️ [IMPORTANT] Configured keybinding is not enough for recovery: global shortcut registration can fail without a success signal to this effective-state logic, so this mitigation can still hide the Dock icon with no usable hotkey. Require successful registration or an immediate Dock-visible fallback when registration fails.

oz-for-oss · 2026-04-29T00:45:40Z

+2. Validate that non-macOS builds ignore the setting and do not expose macOS-specific UI.
+3. Validate that settings persistence and restart behavior match the effective-state rules in Behavior 8 through 12.
+## Open questions
+1. Should this setting be stored only locally on each machine, or should it sync with the existing dedicated Hotkey window settings? The current product expectation is that it persists with the dedicated Hotkey window settings, while non-macOS clients ignore it.


⚠️ [IMPORTANT] This remains an open question while Behavior 12 and the tech spec require persistence with existing dedicated-window settings. Resolve whether the preference syncs or stays local before implementation so settings storage, UI indicators, and non-macOS ignore behavior are consistent.

ShankyJS · 2026-04-29T06:25:10Z

I have reviewed this spec with the help of two different models Opus 4.7 and Codex; both agree that this spec looks to be promising to fix the issue.

If anybody else with experience on the repo could double check, I'd be comfortable taking a stab at implementation now.

As per Claude's:

Accurate:
  - app/src/settings/mod.rs GlobalHotkeyMode (line 258) and QuakeModeSettings (line 328) exist as described, with the exact dropdown labels.
  - app/src/terminal/keys_settings.rs toml paths (global_hotkey.dedicated_window.settings, .enabled, global_hotkey.toggle_all_windows.*) match exactly. Existing helpers like
  set_quake_mode_keybinding_and_write_to_user_defaults follow the naming pattern the spec proposes.
  - crates/warpui/src/platform/mac/objc/{app.m,window.m} and features_page.rs exist.
  - Mutual exclusion of Quake / activation hotkey is real (line 81-90).

  Solid design choices:
  - Effective-state helper that defaults to "visible" on non-mac/missing keybinding is the right safety posture.
  - Setting persisted in QuakeModeSettings (synced) but gated by macOS-only effective state — matches existing SupportedPlatforms::DESKTOP + sync model.
  - NSApplicationActivationPolicyAccessory is the correct AppKit API for this. Note: it does remove the app from Cmd-Tab — spec acknowledges this in product copy (good).

  Minor gaps to flag:
  1. Line ranges are precise (e.g. mod.rs (239-276)) but the AI cited some that drift slightly from current master — review the actual lines, not the numbers, when implementing.
  2. Spec says "add helper or call from Rust" for the activation policy — worth picking one before splitting agents; mixing both creates merge conflicts.
  3. Open question #2 (disable switch vs. allow-but-inactive when keybinding missing) should be resolved before UI work starts.

  Overall: the spec is realistic, the codebase anchors check out, and the recovery safeguards (auto-restore on mode change / cleared keybinding) address the main "user gets locked out" risk. Safe to proceed.

spec: hide Warp icon from Dock for hotkey window

9a033bd

Co-Authored-By: Zach Lloyd <zachlloyd@users.noreply.github.com>

cla-bot Bot added the cla-signed label Apr 29, 2026

oz-for-oss Bot mentioned this pull request Apr 29, 2026

Hide Warp icon from the Dock when using Hotkey window #1154

Open

oz-for-oss Bot commented Apr 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

spec: hide Warp icon from the Dock when using Hotkey window#9349

spec: hide Warp icon from the Dock when using Hotkey window#9349
oz-for-oss[bot] wants to merge 1 commit intomasterfrom
oz-agent/spec-issue-1154

oz-for-oss Bot commented Apr 29, 2026

Uh oh!

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

oz-for-oss Bot left a comment

Uh oh!

oz-for-oss Bot Apr 29, 2026

Uh oh!

oz-for-oss Bot Apr 29, 2026

Uh oh!

ShankyJS commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

oz-for-oss Bot commented Apr 29, 2026

Summary

Validation

Uh oh!

oz-for-oss Bot commented Apr 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

oz-for-oss Bot left a comment

Choose a reason for hiding this comment

Overview

Concerns

Verdict

Uh oh!

oz-for-oss Bot Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

oz-for-oss Bot Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

ShankyJS commented Apr 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

oz-for-oss Bot commented Apr 29, 2026 •

edited

Loading